1. Technical Field of the Invention
This invention relates to telecommunication systems and, more particularly, to a system and method of address resolution in Internet Protocol (IP)-based networks.
2. Description of Related Art
Wireless telecommunication networks are evolving from second generation (2G) circuit-switched networks to third generation (3G) packet-switched networks. A reference architecture for a 3G wireless network is being developed by the Third Generation Partnership Project (3GPP).
Today there are three ways to resolve an address in an IP network: (1) using a Domain Name Server (DNS) to translate an input Uniform Resource Locator/Uniform Resource Identifier (URL/URI) into an IP address, (2) using a Location Server (LS) and the Telephone Routing for IP Protocol (TRIP) Framework to obtain the IP address of a Gateway based on an input E.164 number, and (3) converting an input E.164 number into a domain name in E.164 number (ENUM) format, using the DNS to locate an LS with TRIP capabilities, and obtaining the IP address of a Gateway from the TRIP LS.
The standard addressing mechanism used today for IP networks is based on symbolic names called Uniform Resource Locators (URLs) or Uniform Resource Identifiers (URIs). When an address is entered as a URL/URI, it is translated into an IP address by the public Domain Name System. The Domain Name System is made of servers called Domain Name Servers (DNSs) arranged in a hierarchical structure. If a DNS receives an address query that it cannot resolve, it will typically return the address of a higher level DNS that may be able to resolve the address. Typically the address translation provided by a DNS has a global relevance (i.e., the same IP address is provided regardless of the geographical location of the interrogating node), because the Internet virtually provides global inter-connectivity.
With the introduction of IP telephony, the problem of address resolution was compounded due to the necessity of using classical E.164 numbers, especially for calls routed to and from the Public Switched Telephone Network (PSTN) or the Public Land Mobile Network (PLMN). Calls originating in the PSTN/PLMN and destined for an IP subscriber must be translated from the E.164 number entered by the PSTN/PLMN subscriber to an IP address that is usable in the IP network. Conversely, calls originating in the IP network and destined for the PSTN/PLMN require the use of a Gateway function to perform a protocol translation such as translating from the Session Initiation Protocol (SIP) to Integrated Services User Part (ISUP). The Gateway function also performs a media conversion from packet-switched to circuit-switched transport protocols. As a result, from the IP network perspective, translating an E.164 number requires locating an appropriate Gateway. This is no longer a simple address translation with global relevance, because each operator prefers to have the freedom to chose a Gateway based on the operator's local policies. This means that in one operator's domain, an E.164 number may be translated into the IP address of Gateway-1, whereas, in the domain of another operator, the same E.164 number may be translated into the IP address of Gateway-2.
An alternative method for translating E.164 numbers into IP addresses is currently proposed by the ENUM Internet Engineering Task Force (IETF) working group. This method uses the DNS infrastructure to perform the address resolution, by supplying it with the E.164 number converted into a DNS name. For example, the E.164 number 123 456 7890 may be converted to the DNS name 0.1.2.3.4.5.6.7.8.9. Since the DNS infrastructure is used, the address translation typically has a global relevance. This is useful, for instance, when a PSTN operator decides to connect its network to the IP backbone by installing a SIP-to-ISUP Gateway. A call originated from a SIP subscriber from any geographical location, towards a PSTN subscriber served by this operator, must be routed to the operator's Gateway. Hence, the number series owned by this operator can be converted to the IP address of the Gateway, and this conversion has a global relevance.
Today, it is assumed that when a SIP server needs an address translation for routing purposes, it is able to identify unambiguously what node to interrogate: the DNS or the LS. The current assumptions in 3GPP are:                When a Call State Control Function (CSCF) needs to find a Media Gateway Control Function (MGCF) (the SIP controlling component of a Gateway) in order to go to the PSTN/PLMN, the CSCF interrogates an LS.        When a CSCF needs to find the SIP server that acts as a point of contact in the home network of a called 3GPP subscriber (the Interrogating CSCF or ICSCF), it interrogates a DNS.        In general, URL/URIs are translated by DNSs, and E.164 numbers are translated by LSs.        
With the convergence of the telecom and datacom worlds, reflected in the 3G-all-IP networks, the user will be given the freedom to use various addresses to call another party. Moreover, the called party may not only be a SIP or PSTN/PLMN subscriber, but may also be an H.323 subscriber. Adding to this complexity, SIP subscribers and H.323 subscribers may be addressed using either a URL/URI or an E.164 number. The set of currently used assumptions lead to the following addressing problems in a 3G-all-IP network:                When the caller specifies the called party using an E.164 number, it is not known whether the called party is a PSTN/PLMN subscriber, an H.323 subscriber, or a SIP 3GPP Multimedia subscriber. Telephone numbers require translation using a DNS and a TRIP LS; H.323 addresses require translation using a DNS and a non-TRIP LS; and SIP addresses require translation using a DNS only. Therefore, when the Serving CSCF (S-CSCF) of the caller needs to translate the E.164 number, it is not clear which database(s) should be interrogated—a DNS (as described by the ENUM group), a non-TRIP LS, or a TRIP LS (as in the TRIP framework).        If the caller specifies the called party using a URL/URI, the S-CSCF of the caller will automatically interrogate the DNS. However, if the URL/URI is the address of an H.323 subscriber, the DNS will most likely provide the IP address of the called party's Gatekeeper, which is of no use to the caller's S-CSCF since it does not understand the H.323 protocol. In this case the S-CSCF needs to obtain the address of a SIP-H.323 MGCF, and therefore should interrogate the LS. However, there is currently no methodology to enable this interrogation. Furthermore, there is no provision for the DNS to return the type of subscriber (for example, H.323 or SIP) to the S-CSCF so that it can take the appropriate action.        
Thus, in a 3G-all-IP network, a subscriber can be addressed through a SIP URL/URI or an E.164 number. A SIP URL/URI takes the form of sip.user@domain. An E.164 number can represent a telephone number, a SIP subscriber, or an H.323 subscriber. When the E.164 number is entered, it is not known which one it represents, and each one must be translated by a different node. Thus, there are presently several very different address resolution schemes, and none of them are connected or coordinated in any way.
In order to overcome the disadvantage of existing solutions, it would be advantageous to have a system and method of address resolution in IP-based networks that provides a uniform methodology for address resolution. The present invention provides such a system and method.